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Abstract 


This informational document details a protocol to load Manufacturer Usage Description (MUD) 
definitions from RFC 8520 for devices that do not have them integrated. 


This document is published to inform the Internet community of this mechanism to allow 
interoperability and to serve as a basis of other standards work if there is interest. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor 
has chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9238. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. 
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1. Introduction 


The Manufacturer Usage Description (MUD) [RFC8520] defines a YANG data model to express 
what sort of access a device requires to operate correctly. That document additionally defines 
three ways for the device to communicate the MUD URL (i.e., the URL of the resulting MUD file in 
JSON [RFC8259]) to a network enforcement point: via DHCP, within an X.509 certificate extension, 
and via the Link Local Discovery Protocol (LLDP). 


Each of the above mechanisms conveys the MUD URL in band and requires modifications to the 
device firmware. Most small Internet of Things (IoT) devices do not have LLDP and often have 
very restricted DHCP clients. Adding LLDP or DHCP options requires at least some minimal 
configuration change and possibly entirely new subsystems. Meanwhile, use of the PKIX 
certification extension only makes sense as part of a larger deployment based on an Initial 
Device Identifier (IDevID) [[EEE802-1AR], for instance, as described in [RFC8995]. 


In the above cases, these mechanisms can only be implemented by persons with access to modify 
and update the firmware of the device. 


In the meantime, there is a chicken or egg problem [chickenegg]. That is, manufacturers are not 
motivated to (and thus likely do not) include MUD URLs in their products, as they believe that 
there are no gateways using those URLs. At the same time, gateways have little incentive to (and 
thus likely do not) include code that processes MUD URLs, as it is believed that no products have 
or disseminate URLs. 


The protocol described in this document allows any person with physical access to the device to 
affix a reference to a MUD URL that can later be scanned by an end user. 


The QkR-based protocol is presented as a convenient alternative when the mechanisms from 
[RFC8520] are not available to use on the device or the gateway. 


Affixing a sticker can be done by: 


e the marketing department of the manufacturer, 

e an outsourced assembler plant, 

e value-added resellers (perhaps in response to a local request for proposal (RFP)), 
e a company importing the product (possibly to comply with a local regulation), 


e a network administrator (perhaps before sending devices home with employees or to remote 
sites), and 


e a retailer as a value-added service. 


QR codes are informally described in [qrcode] and formally defined in [isoiec18004]. The protocol 
described in this document uses a QR code to encode the MUD URL. Specifically, the protocol 
leverages the data format from the Reverse Logistics Association's Standardized Quick Response 
for Logistics [SQRL]. 
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SQRL codes are being put on devices via a sticker or via laser etching into the case in order to deal 
with many situations but specifically for end-of-life processing for the device. An important idea 
behind the effort is that clearly identifying a product permits appropriate disposal, 
refurbishment, or recycling of the components of the product. 


There are also use cases for SQRL in which the codes are used as part of regular maintenance for 
a product. 


SQRL is an application of the 12N Data Identifier system specified by the ANSI MH10.8.2 
Committee [mh10] in a format appropriate for QR codes, as well as other things like 
Normalization Form C (NFC) transmissions. 


QR code generators are available as web services or as programs, suchas [qrencode]. 


Section 5 summarizes the considerations contained in "Updating files vs Updating MUD URLs" 
(Section 7.1 of [MUD-URLS]). Due to the immutable nature of the QR code, MUD URLs in this 
document will need to be non-firmware specific. 


2. Terminology 


Although this document is not an IETF Standards Track publication, it adopts the conventions for 
normative language to provide clarity of instructions to the implementer. The key words "MUST", 
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 


Readers should be familiar with the terminology in [RFC8520], including: MUD file, MUD URL, 
manufacturer, MUD manager, and controller. 


3. Protocol 


The QR code protocol builds upon the work by [SQRL]. That protocol is very briefly described in 
Section 3.1. Then, the list of needed Data Records to be filled in is explained. 


3.1. The SQRL Protocol 


[SQRL] documents an octet protocol that can be efficiently encoded into QR codes using a 
sequence of US-ASCII bytes, plus six control codes (see Section 3.1 of [SQRL]): 


e <RS> Record Separator (US-ASCII 30) 

e <EoT> End of Transmission (US-ASCII 4) 

e <FS> Field Separator (US-ASCII 28) 

e <GS> Group Separator (US-ASCII 29) 

e <US> Unit Separator (US-ASCII 31) 

e Concatenation Operator (US-ASCII 43: "+" 


Richardson, et al. Informational Page 4 


RFC 9238 Loading MUD URLs from QR Codes May 2022 


Section 7.2 of [SQRL] gives the details, which can be summarized as: 


1. The QR code header starts with: 


Le" <RS> "96" <GS> TANG 


2. Include one or more Data Records. This consists of a four-letter Field Identifier, followed by 
US-ASCII characters terminated with a <Unit Separator>. 


3. End with: 
<RS><EoT> 


Additionally, there are optional flags that may be present in every Data Record, as described in 
Section 7.4 of [SQRL]. These flags have no bearing on MUD processing. A parser that is only 
collecting MUD URLs will not need to parse those flags. A general-purpose SQRL parser will need 
more complexity. 


Field Separator characters are used in SQRL to signify the beginning of a new unit of data. A 
MUD-specific parser that encounters a Field Separator and has not yet collected the right MUD 
information MUST ignore the characters collected so far and then restart. 


Environment records, as described in Section 7.4 of [SQRL], look and act exactly as fields, with a 
special Field Identifier. They serve no purpose when looking for MUD information and MAY be 
ignored. 


3.2. Manufacturer Usage Descriptions in SQRL 


3.2.1. B000 Company Name 


The B000 Data Record is mandatory in [SQRL]. It MUST be in US-ASCII representation. It should be 
a representation of the company or brand name. It SHOULD match the ietf-mud/mud/mfg-name 
in the MUD file; however, the MUD file can contain arbitrary UTF-8 for this name, while the SQRL 
files are expected to be 7-bit US-ASCII. 


3.2.2. B001 Product Name 


The B001 Data Record is optionalin [SQRL]. It is the Product Name in US-ASCII. Its presence is 
RECOMMENDED. Some third parties that create QR code stickers might not know the product 
name with 100% certainty and MAY prefer to omit this rather than create further confusion. 


3.2.3. B002 Model Number 


The B002 Data Record is optionalin [SQRL] but is MANDATORY in this profile. It is the Model 
Name in US-ASCII. It SHOULD match the optional ietf-mud/mud/model-name in the MUD file if 
that entry is present in the MUD file. MUD files can contain arbitrary UTF-8 for the model-name, 
while the SQRL files are expected to be 7-bit US-ASCII. 
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If a third party that is creating QR codes cannot locate an official model number when creating 
their MUD file and QR code, then the third party SHOULD make one up. 


3.2.4. MUD URL Data Record 


Anew Field Identifier has been assigned by the Reverse Logistics Association, which is "M180". 
This record MUST be filled with the MUD URL. 


Short URLs are easier to encode into a QR code because they require fewer pixels of QR code. 
More content in the QR code requires a bigger image. 


Use of URL shortening services (see [URLshorten]) can be useful, provided that the service is 
stable throughout the lifetime of the device and QR code and that the privacy stance of the service 
is well understood. The Security Considerations section of [RFC3986] applies, particularly Section 
rae 


Section 8.1 of [SQRL] also has some good advice on longevity concerns with URLs. 


The URL provided MUST NOT have a query (?) portion present. If one is present, the query portion 
MUST be removed before processing. 


3.2.5. Device MAC Address 


If a Media Access Control (MAC) address is used as a unique device identifier (which is 
RECOMMENDED if possible), then it MUST be included in this Data Record. 


Section 9.10 of [SQRL] defines the Data Record "MO6C" as the MAC address. No format for the MAC 
address is provided in that document. 


In this document, it is RECOMMENDED that 12 (or 16) hex octets are used with no spaces or 
punctuation. (16 octets are used in the IEEE 64-bit Extended Unique Identifier (EUI-64) format 
used in [IEEE.802.15.4] and some next generation Ethernet proposals). In this document, it is 
RECOMMENDED that uppercase hexadecimal letters be used. 


Parsers that find punctuation (such as colons (":"), dashes ("-"), US-ASCII Space (32), US-ASCII TAB 
(0), US-ASCII linefeed (10), or US-ASCII carriage return (13)) MUST skip over the punctuation. 
Parsers MUST tolerate hexadecimal in uppercase, lowercase, and even mixed case. Systems 
SHOULD canonicalize it to uppercase. 


4. Applicability 


The use of stickers to convey MUD URLs would appear to have little value when the stickers are 
applied by the end-user organization and consumed by the same. This is particularly the case 
when the QR code does not include the device MAC address. In sucha situation, the installer 
handling the device would scan the QR code to get the appropriate MUD file reference and have 
to input the associated MAC address as well. 
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In sucha case, one might wonder why the installer couldn't just enter the appropriate MAC 
address and select the appropriate Access Control Lists (ACLs) for the device. Then a MUD file or 
QR code to convey the MAC address would not be needed. However, the use of a MUD file (or QR 
code or other way to convey the MAC address) is advantageous because it offers several layers of 
indirection: 


1. The ACLs for a given device may be added or removed. 
2. The ACLs may refer to DNS names, which may map to IPv4 or IPv6 addresses. 


3. The entire file may be replaced and may also include supply chain information, such as 
Software Bill of Materials (SBOM). 


In addition, the mechanism to install a new device (MAC address) to MUD file mapping does not 
need to permit any other network security settings to be alterable by the person doing the 
installation. 


5. Generic URL or Version-Specific URL 


MUD URLs that are communicated in band by the device and that are programmed into the 
device's firmware may provide a firmware-specific version of the MUD URL. The advantage of 
this is that the resulting ACLs enforced in the network are specific to the needs of that version of 
the firmware. 


A MUD URL that is affixed to the device with a sticker or etched into the case cannot be changed. 


Given the considerations of "Updating MUD URLs vs Updating MUD files" (Section 6.1 of [MUD- 
URLS]), it is prudent to use a MUD URL that points to a MUD file that will only have new features 
added over time and never have features removed. To recap, if a feature is removed from the 
firmware and the MUD file still permits it, then there is a potential hole that could perhaps be 
exploited. The opposite situation, where a MUD file wrongly forbids something, leads to false 
positives in the security system, and the evidence is that this results in the entire system being 
ignored. Preventing attacks on core infrastructure may be more important than getting the ACL 
perfect. 


When the firmware eventually receives built-in MUD URL support, then a more-specific URL may 
be used. 


Note that in many cases, it will be third parties who are generating these QR codes, so the MUD file 
may be hosted by the third party. 


6. Crowd Supply of MUD Files 


At the time of writing, the IETF MUD is a new IETF Proposed Standard. Hence, IoT device 
manufacturers have not yet provided MUD profiles for their devices. Aresearch group at the 
University of New South Wales (UNSW Sydney) has developed an open-source tool, called 
MUDgee [MUDgee], which automatically generates a MUD file (profile) for an IoT device from its 
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traffic trace in order to make this process faster, easier, and more accurate. Note that the 
generated profile completeness solely depends on the completeness of the input traffic traces. 
MUDgee assumes that all the activity seen is intended and benign. 


UNSW researchers have applied MUDgee to about 30 consumer IoT devices from their lab testbed 
and publicly released their MUD files [MUDfiles]. MUDgee can assist IoT manufacturers in 
developing and verifying MUD profiles, while also helping adopters of these devices to ensure 
they are compatible with their organizational policies. 


Similar processes have been done in a number of other public and private labs. One of the strong 
motivations for this specification is to allow for this work to leave the lab and to be applied in the 
field. 


7. Privacy Considerations 


The presence of the MUD URL in the QR code reveals the manufacturer of the device, the type or 
model of the device, and possibly the firmware version of the device. 


The MAC address of the device will also need to be present, and this is potentially Personally 
Identifiable Information (PII). Such QR codes should not be placed on the outside of the 
packaging and only on the device itself, ideally on a non-prominent part of the device (e.g., the 
bottom). 


The QR code sticker should not be placed on any part of the device that might become visible to 
machine vision systems in the same area. This includes security systems, robotic vacuum 
cleaners, or anyone taking a picture with a camera. Such systems may store the picture(s) in such 
a way that a future viewer of the image will be able to decode the QR code, possibly through an 
assembly of multiple pictures. Of course, the QR code is not, however, a certain indicator that the 
device is present, only that the QR code sticker that came with the device is present. 


The use of URL shorting services discussed in Section 3.2.4 may result in trading convenience and 
efficiency with privacy, since the service provider might leverage per-device or per-customer, 
short URLs to track and correlate requests. 


8. Security Considerations 


8.1. QR Codes Are Not Assurances 


The mere presence of a QR code on a device does not in itself create any security issues on its 
own. Neither an attached paper sticker nor a laser-etched code in a plastic case will affect the 
device operation. 


The QR code is not active; in general, it is not able to communicate using nearby networks. It is 
conceivable that something more active is concealed in the sticker, e.g., an NFC or a Radio 
Frequency Identification (RFID) tag. But, any sticker could contain sucha thing, e.g., on some 
university campuses, stickers are often used as part of political campaigns and can be found 
attached all over the place. 
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Security issues that this protocol creates are related to assumptions that the presence of the QR 
code might imply. The presence of the QR code may imply to some owners or network operators 
that the behavior of the device has been vetted by some authority. It is here that some caution is 
required. 


A possibly bigger risk from application of MUD file stickers to devices is that they may begin to 
convey a sense of safety to users of the device. The presence of the sticker, possibly with the logo 
of the physical establishment in which the device is located, could convey to occupants of the 
establishment that this device is an official device, for instance, a university that only deploys 
sensors on the university campus that have been vetted for compliance against a MUD 
definition. 


The risk is then of social engineering, e.g., any device with a reasonable-looking QR code may be 
seen as a trusted device (even though such trust is not justified based on that evidence). An 
attacker that wishes to infiltrate their own devices need only suitably camouflage the device with 
an appropriate sticker in order to convey legitimacy. 


8.2. MUD Files Can Have Signatures 


The network operator who takes the MUD file designated by the QR code needs to be careful that 
they are validating the signature on the MUD file. The network operator needs to verify that the 
file is intact and that the signer of the file is authorized to sign MUD files for that vendor, or if a 
MUD file is a crowd-sourced definition, they need to establish if it can be trusted. [RFC8520] does 
not define any infrastructure to authenticate or authorize MUD file signers. 


8.3. URL Shortening Services Can Change Content 


If a URL shortening service is used, it is possible that the MUD controller will be redirected to 
another MUD file with different content. The use of MUD signatures can detect attacks on the 
integrity of the file. To do this, the MUD controller needs to be able to verify the signature on the 
file. 


If a Trust-On-First-Use (TOFU) policy is used for signature trust anchors, then the URL shortening 
service can still attack if it substitutes content and signature on the first use. MUD controllers and 
the people operating them need to be cautious when using TOFU. 


8.4. MUD QR Code Stickers Could Be Confused 


Another issue with the stickers is that the wrong sticker could be applied to a device by a reseller 
or another trusted party, either in error or via some physical or socially engineered attack against 
that party. The network operator now onboards a device and applies what they think is a 
legitimate network policy for the device in their hands, only it is in fact a policy for another kind 
of device. 


Careful examination of stickers is in order! 
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8.5. QR Code Can Include a MAC Address 


Inclusion of the device-specific MAC address (described in Section 3.2.5) in the QR code makes use 
of the MUD code much easier, as it identifies the device specifically. If the MAC address is not 
included, then a network operator, having the device in their hands, has to associate the policy 
with the device through some other interface. 


Despite the significant advantage of having the MAC address included, it is unlikely that third- 
party stickers will include it. Including the MAC address requires that a unique sticker with a QR 
code be created for each device. This is possible if the sticker is applied by a manufacturer; it is 
already common to have a serial number and MAC address on the outside of the device. In that 
case, if the QR code is part of that sticker, then the customization problem is not that complex. 


For cases where a third party has produced the QR code, it is likely that every device of a 
particular model will have the same QR code applied, omitting the MAC address. This increases 
the possibility that the wrong policy will be applied to a device. 


9. IANA Considerations 


This document has no IANA actions. 
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